Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flag to disable dune diagnostics #1221

Merged
merged 5 commits into from
Jan 5, 2024
Merged

Conversation

EduardoRFS
Copy link
Contributor

@EduardoRFS EduardoRFS commented Jan 3, 2024

Context

I like to work with incomplete files a lot and playing around with them before actually saving, going through many intermediary steps.

But due to how OCaml LSP behaves as soon as you save a file with a single error coming from dune, that error will be there until you save it again, which is quite annoying.

So I've been using for almost 2 years a patched version of the OCaml LSP without dune diagnostics, this is hopefully that but as an opt-in option.

Patch

I tried to make the patch the least invasive, keeping all the features except the dune reporting inside of files, to do that I disable the entire diagnostics loop, this may be too much, but in the last years I never detected any issues.

How to use

{
  "ocaml.sandbox": {
    "kind": "global"
  },
  "ocaml.server.args": [
    "--no-dune-diagnostics"
  ]
}

Related

@tjdevries
Copy link

Should this use the workspace configuration settings ( like this https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeConfiguration )?

Then you should be able to toggle it as well while you're editing (and goes with the rest of the configuration of the LSP)

@EduardoRFS
Copy link
Contributor Author

@tjdevries I thought about it, but I was not sure if OCaml LSP already had any options, but after checking it again, that seems to be the case, such as "extendedHover" and VSCode OCaml Platform even exposes that.

And it even already supports the on change, the only downside is that I need to implement that, but will do, also keeping the diagnostics_loop running is likely better.

@EduardoRFS EduardoRFS force-pushed the 5.2-no-dune branch 4 times, most recently from ebebf08 to 5e87542 Compare January 4, 2024 01:02
@EduardoRFS
Copy link
Contributor Author

EduardoRFS commented Jan 4, 2024

This patch works, but it shines light in a likely bug, ocaml-lsp doesn't request the configs when starting the LSP, this means that it only detects the settings when changing them.

This seems to also explain why sometimes codelens is not loaded as the default is codelens = Some { enable = false }, since #1134.

https://github.com/EduardoRFS/vscode-ocaml-platform/tree/no-dune

@voodoos
Copy link
Collaborator

voodoos commented Jan 4, 2024

Maybe another option would be to invalidate the diagnostics as soon as the buffer is edited ? (Not sure if that's allowed by the protocol however).

@EduardoRFS
Copy link
Contributor Author

@voodoos I think this would be possible, but in general seems weird, if you're changing the file is likely that you're trying to solves some of those errors, removing the errors would make that harder for developers on a single screen.

@EduardoRFS
Copy link
Contributor Author

I think the weird behavior of not pushing config was an issue with vscode-ocaml-platform and even if it is not, this patch seems to be safer overall.

ocamllabs/vscode-ocaml-platform#1321

@voodoos
Copy link
Collaborator

voodoos commented Jan 5, 2024

@voodoos I think this would be possible, but in general seems weird, if you're changing the file is likely that you're trying to solves some of those errors, removing the errors would make that harder for developers on a single screen.

Another way to think about it is that most compiler errors for the currently edited buffer are redundant with the ones already reported by Merlin. The most useful errors enabled by the dune-diagnostics are signature mismatches errors, that Merlin is not able to provide.

We might want to only report these for the active buffer ? This would also solve the issue of having duplicated type errors when the compiler prints them differently by Merlin.

@EduardoRFS
Copy link
Contributor Author

The most useful errors enabled by the dune-diagnostics are signature mismatches errors, that Merlin is not able to provide.

I don't want to see those either, because again, if I make it match the signature without saving, it will be red for me. In fact I'm much rather have a false positive that I discover when trying to compile than a false negative that is annoying me while working.

But this is clearly a personal opinion and doesn't match other's experiences, so I would actually like the flag.

In my opinion, having dune diagnostics for any type error is just a failure of Merlin and we should work on that.

Copy link
Collaborator

@voodoos voodoos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made a first round of review with a few remarks. I believe there is some cleaning to do in the Dune module.

I am not opposed to adding a flag to let users choose if they want to use the feature or not. It's sad that the LSP protocol doesn't provide a standardize way to specify such simple options.


/**
* Enable/Disable Dune diagnostics
* @default false
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default is actually true

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

; dune_diagnostics : DuneDiagnostics.t
[@key "duneDiagnostics"]
[@default DuneDiagnostics.{ enable = true }]
[@yojson_drop_default ( = )]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why previous options were added as Json.Nullable_option.t ? What is different with that new one ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, my bet is that it was to be able to distinguish between default and null, but it doesn't matter in any of them, as they all treat both options the same, I can change the other ones also if you want

@aspeddro may know better

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To help here I moved all of them to the simpler format.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The simpler format is fine, but we'd appreciate it if it was done in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I placed the simpler type in a different commit, to make it easier to review. If you want I can remove it, but I would be glad if we can avoid bikeshedding here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my comments are "bikeshedding", then you will have a difficult time contributing to this repository. I like to keep PR's focused on one of: bug fixing, new features, refactoring. So yes, keep it focused for the reviewers and move the unrelated stuff to separate PR's.

@@ -8,6 +8,9 @@ end

type t

(** enabled by default *)
val enable_diagnostics : bool ref
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see you never update this reference. Are the modifications in this module leftovers from a previous implementation ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, nice catch, my bad I forgot to review the new implementation.

Diagnostics.set_report_dune_diagnostics
(State.diagnostics state)
~report_dune_diagnostics:
state.configuration.data.dune_diagnostics.enable
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really fan of relying on a reference to update the configuration of the diagnostics, but I guess we have no choice ?

Also it looks like you are updating the config with the old value. The new value is in configuration.data.dune_diagnostics.enable, not state.configuration.data.dune_diagnostics.enable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, yeah I had fixed this bug in the other branch but forgot to push it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also like to not use mutation in general, but Diagnostics already had mutation, so I decided to go with that as the alternative would require quite a bit of work due to concurrency and already mutable state.

@EduardoRFS EduardoRFS force-pushed the 5.2-no-dune branch 2 times, most recently from a93a46a to f0bb3cb Compare January 5, 2024 16:10
@EduardoRFS EduardoRFS requested a review from voodoos January 5, 2024 16:10
@EduardoRFS
Copy link
Contributor Author

Tested this patch with the VSCode OCaml extension and it's working as intended, both codelens and duneDiagnostics.

@coveralls
Copy link

coveralls commented Jan 5, 2024

Pull Request Test Coverage Report for Build 4079

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.004%) to 20.384%

Totals Coverage Status
Change from base Build 4053: 0.004%
Covered Lines: 4851
Relevant Lines: 23798

💛 - Coveralls

| _ -> now [])
| TextDocumentCodeLens req ->
if state.configuration.data.codelens.enable then
later text_document_lens req
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes seem unrelated. Separate PR for them please.

@EduardoRFS EduardoRFS force-pushed the 5.2-no-dune branch 3 times, most recently from 03d17b5 to 054b9e2 Compare January 5, 2024 19:23
@EduardoRFS
Copy link
Contributor Author

Just tested the patch, it is working.

_
Signed-off-by: Rudi Grinberg <[email protected]>
_
Signed-off-by: Rudi Grinberg <[email protected]>
_
Signed-off-by: Rudi Grinberg <[email protected]>
@rgrinberg rgrinberg added this to the 1.18.0 milestone Jan 5, 2024
@rgrinberg
Copy link
Member

Alright, this is good to go after some minor modifications.

@rgrinberg rgrinberg merged commit cb06208 into ocaml:master Jan 5, 2024
9 checks passed
@EduardoRFS EduardoRFS deleted the 5.2-no-dune branch January 5, 2024 21:05
@EduardoRFS
Copy link
Contributor Author

Thank you

@jakubrpawlowski
Copy link

Thank you so much for this update! 🙇‍♂️

@felipecrv
Copy link

I think this will improve my experience as well.

PizieDust added a commit to PizieDust/ocaml-lsp that referenced this pull request Mar 8, 2024
lint

change from italics to code pill

Completion for `in` keyword (ocaml#1217)

feat(auto-completion): auto-complete `in` (in a hacky way) in .ml files

Prepare release 1.17.0 (ocaml#1219)

* chore: restore lost version number in changes
     (erased in c8c1096)

* chore: bump version number in changes before release

Add flag to disable dune diagnostics (ocaml#1221)

* add config to control dune diagnostics

lint

update changelog
voodoos added a commit to voodoos/opam-repository that referenced this pull request Jul 5, 2024
CHANGES:

## Features

- Introduce a configuration option to control dune diagnostics. The option is
  called `duneDiganostics` and it may be set to `{ enable: false }` to disable
  diagnostics. (ocaml/ocaml-lsp#1221)

- Support folding of `ifthenelse` expressions (ocaml/ocaml-lsp#1031)

- Improve hover behavior (ocaml/ocaml-lsp#1245)

  Hovers are no longer displaye on useless parsetree nodes such as keywords,
  comments, etc.

  Multiline hovers are now filtered away.

  Display expanded ppx's in the hover window.

- Improve document symbols (ocaml/ocaml-lsp#1247)

  Use the parse tree instead of the typed tree. This means that document
  symbols will work even if the source code doesn't type check.

  Include symbols at arbitrary depth.

  Differentiate functions / types / variants / etc.

  This now includes PPXs like `let%expect_test` or `let%bench` in the outline.

- Introduce a `destruct-line` code action. This is an improved version of the
  old `destruct` code action. (ocaml/ocaml-lsp#1283)

- Improve signature inference to only include types for elements that were
  absent from the signature. Previously, all signature items would always be
  inserted. (ocaml/ocaml-lsp#1289)

- Add an `update-signature` code action to update the types of elements that
  were already present in the signature (ocaml/ocaml-lsp#1289)

- Add custom
  [`ocamllsp/merlinCallCompatible`](https://github.com/ocaml/ocaml-lsp/blob/e165f6a3962c356adc7364b9ca71788e93489dd0/ocaml-lsp-server/docs/ocamllsp/merlinCallCompatible-spec.md)
  request (ocaml/ocaml-lsp#1265)

- Add custom [`ocamllsp/typeEnclosing`](https://github.com/ocaml/ocaml-lsp/blob/109801e56f2060caf4487427bede28b824f4f1fe/ocaml-lsp-server/docs/ocamllsp/typeEnclosing-spec.md) request (ocaml/ocaml-lsp#1304)

## Fixes

- Detect document kind by looking at merlin's `suffixes` config.

  This enables more lsp features for non-.ml/.mli files. Though it still
  depends on merlin's support. (ocaml/ocaml-lsp#1237)

- Correctly accept the `--clientProcessId` flag. (ocaml/ocaml-lsp#1242)

- Disable automatic completion and signature help inside comments (ocaml/ocaml-lsp#1246)

- Includes a new optional/configurable option to toggle syntax documentation. If
  toggled on, allows display of syntax documentation on hover tooltips. Can be
  controlled via environment variables and by GUI for VS code. (ocaml/ocaml-lsp#1218)

- For completions on labels that the LSP gets from merlin, take into account
  whether the prefix being completed starts with `~` or `?`. Change the label
  completions that start with `?` to start with `~` when the prefix being
  completed starts with `~`. (ocaml/ocaml-lsp#1277)

- Fix document syncing (ocaml/ocaml-lsp#1278, ocaml/ocaml-lsp#1280, fixes ocaml/ocaml-lsp#1207)

- Stop generating inlay hints on generated code (ocaml/ocaml-lsp#1290)

- Fix parenthesizing of function types in `SignatureHelp` (ocaml/ocaml-lsp#1296)

- Fix syntax documentation rendering (ocaml/ocaml-lsp#1318)
avsm pushed a commit to avsm/opam-repository that referenced this pull request Sep 5, 2024
CHANGES:

## Features

- Introduce a configuration option to control dune diagnostics. The option is
  called `duneDiganostics` and it may be set to `{ enable: false }` to disable
  diagnostics. (ocaml/ocaml-lsp#1221)

- Support folding of `ifthenelse` expressions (ocaml/ocaml-lsp#1031)

- Improve hover behavior (ocaml/ocaml-lsp#1245)

  Hovers are no longer displaye on useless parsetree nodes such as keywords,
  comments, etc.

  Multiline hovers are now filtered away.

  Display expanded ppx's in the hover window.

- Improve document symbols (ocaml/ocaml-lsp#1247)

  Use the parse tree instead of the typed tree. This means that document
  symbols will work even if the source code doesn't type check.

  Include symbols at arbitrary depth.

  Differentiate functions / types / variants / etc.

  This now includes PPXs like `let%expect_test` or `let%bench` in the outline.

- Introduce a `destruct-line` code action. This is an improved version of the
  old `destruct` code action. (ocaml/ocaml-lsp#1283)

- Improve signature inference to only include types for elements that were
  absent from the signature. Previously, all signature items would always be
  inserted. (ocaml/ocaml-lsp#1289)

- Add an `update-signature` code action to update the types of elements that
  were already present in the signature (ocaml/ocaml-lsp#1289)

- Add custom
  [`ocamllsp/merlinCallCompatible`](https://github.com/ocaml/ocaml-lsp/blob/e165f6a3962c356adc7364b9ca71788e93489dd0/ocaml-lsp-server/docs/ocamllsp/merlinCallCompatible-spec.md)
  request (ocaml/ocaml-lsp#1265)

- Add custom [`ocamllsp/typeEnclosing`](https://github.com/ocaml/ocaml-lsp/blob/109801e56f2060caf4487427bede28b824f4f1fe/ocaml-lsp-server/docs/ocamllsp/typeEnclosing-spec.md) request (ocaml/ocaml-lsp#1304)

## Fixes

- Detect document kind by looking at merlin's `suffixes` config.

  This enables more lsp features for non-.ml/.mli files. Though it still
  depends on merlin's support. (ocaml/ocaml-lsp#1237)

- Correctly accept the `--clientProcessId` flag. (ocaml/ocaml-lsp#1242)

- Disable automatic completion and signature help inside comments (ocaml/ocaml-lsp#1246)

- Includes a new optional/configurable option to toggle syntax documentation. If
  toggled on, allows display of syntax documentation on hover tooltips. Can be
  controlled via environment variables and by GUI for VS code. (ocaml/ocaml-lsp#1218)

- For completions on labels that the LSP gets from merlin, take into account
  whether the prefix being completed starts with `~` or `?`. Change the label
  completions that start with `?` to start with `~` when the prefix being
  completed starts with `~`. (ocaml/ocaml-lsp#1277)

- Fix document syncing (ocaml/ocaml-lsp#1278, ocaml/ocaml-lsp#1280, fixes ocaml/ocaml-lsp#1207)

- Stop generating inlay hints on generated code (ocaml/ocaml-lsp#1290)

- Fix parenthesizing of function types in `SignatureHelp` (ocaml/ocaml-lsp#1296)

- Fix syntax documentation rendering (ocaml/ocaml-lsp#1318)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

false negatives on unsaved files
7 participants